Smoke Test Plan

What changed

This PR replaces the HTTP call to the Go /api/interpreters endpoint with an in-process TypeScript call (getInterpreterDefaults()), removes the Go endpoint entirely, and adds requiresPython/requiresR fill-in logic to UpdateConfigWithDefaults.

Two code paths in state.ts are affected:

1. refreshConfigurations() — called on startup, when .posit/publish/*.toml files change, and on manual refresh
2. getSelectedConfiguration() — called when rendering content, refreshing packages, managing secrets, editing configs, deploying, etc.

Prerequisites

• A workspace with at least one .posit/publish/*.toml configuration that has a python and/or r section
• Python and/or R installed and on PATH
• Optionally: a project with .python-version, pyproject.toml, DESCRIPTION, or renv.lock for requiresPython/requiresR coverage

Test cases

1. Extension startup — Python project

1. Open a project that has a .posit/publish/*.toml config with a python section
2. The sidebar should load without errors
3. The Python packages panel should display — confirming python.version, python.packageFile, and python.packageManager were populated from the TypeScript detector

Pass: Sidebar renders, Python packages section shows the correct package file and packages. No errors in the Output panel.

2. Extension startup — R project

1. Open a project with a .posit/publish/*.toml config that has an r section
2. The R packages panel should display correctly

Pass: R packages section shows packages. No errors.

3. Configuration file change triggers refresh

1. With the extension running, edit a .posit/publish/*.toml file (e.g. change the title)
2. The file watcher should trigger refreshConfigurations()
3. The sidebar should update without errors

Pass: Changes reflected in sidebar. No errors in Output panel.

4. Selecting a deployment loads its configuration

1. If multiple deployments exist, switch between them in the sidebar
2. Each switch calls getSelectedConfiguration(), which invokes getInterpreterDefaults()

Pass: Configuration loads for each deployment. Python/R package sections update appropriately.

5. Python not on PATH

1. Temporarily rename/remove Python from PATH (or test on a machine without Python)
2. Open a project with a Python configuration

Pass: Extension loads without crashing. The Python section should still appear but with empty/default version. No unhandled exceptions.

6. R not on PATH

1. Same as above but for R

Pass: Extension loads without crashing. R section gracefully handles missing interpreter.

7. Mixed project (Python + R)

1. Open a project whose .toml config has both python and r sections
2. Both package panels should populate correctly

Pass: Both Python and R packages display. Both versions are detected.

8. Deploy still works

1. Select a deployment and click Deploy
2. The deployment should proceed — this exercises the full config-loading pipeline including interpreter defaults

Pass: Deployment completes successfully. The deployed configuration has correct interpreter versions.

9. Go endpoint is gone (negative test)

1. With the extension running, attempt to call GET /api/interpreters?dir=. directly via curl against the Go backend port

Pass: Returns 404 or "not found" — confirming the route was removed and nothing else depends on it.

10. requiresPython / requiresR populated

1. Create a project with a .python-version file (e.g. 3.11) and a DESCRIPTION file with Depends: R (>= 4.1.0)
2. Open the project and check the configuration that gets written during deployment

Pass: The requiresPython and requiresR fields are populated in the configuration defaults.

Automated coverage

Root cause analysis: relative projectDir passed to TypeScript interpreter module

The bug

After replacing the Go /interpreters endpoint with the new TypeScript interpreter detection module (src/interpreters/), the sidebar would erroneously show the Scan button for projects that have a requirements.txt. The interpreter defaults (e.g. packageFile: "requirements.txt") were coming back empty even though the file existed on disk.

Root cause

The two call sites in state.ts that invoke getInterpreterDefaults() were passing relative projectDir values:

1. getSelectedConfiguration() passed contentRecord.projectDir — a relative path like "report-GUD1"
2. refreshConfigurations() passed the literal string "."

The TypeScript module uses these paths for filesystem operations (fileExistsAt, execFile cwd), which resolve relative to process.cwd() of the extension host process — not the user's workspace root. So requirements.txt detection was looking in the wrong directory and always failing.

The old Go endpoint received the same relative paths but resolved them server-side against its known base directory, so it worked correctly. When we removed that server-side resolution by moving to TypeScript, we lost that implicit path fixup.

The fix

Resolve projectDir to an absolute path in state.ts before passing it to the TypeScript module:

• getSelectedConfiguration(): path.join(root, contentRecord.projectDir) — joins the workspace root with the content record's relative project dir
• refreshConfigurations(): pass root directly instead of "."

root comes from workspaces.path() which returns the workspace folder's fsPath (already absolute).

Test coverage added

• state.test.ts: Asserts getInterpreterDefaults receives /workspace/<projectDir> (absolute) in the getSelectedConfiguration test, and "/workspace" (not ".") in a new refreshConfigurations test
• integration.test.ts: Added an explicit test confirming getInterpreterDefaults correctly detects requirements.txt when given an absolute projectDir path